1. Field of the Invention
This invention is concerned with storage utilization and selection apparatus and methods for a multi-microprocessor implemented data processing system that emulates a main frame system. More particularly, this invention is directed to improving the performance of such a system insofar as selection between control and main storage is concerned.
2. Description of the Prior Art
The emulation of "mainframe" data processing systems through the use of microprocessors has become a reality. A typical main frame data processing system would be any one of the System/370 (S/370) models available from International Business Machines Corporation. The PC/XT370, a "desktop" System/370, also available from International Business Machines corporation, is one example of such a microprocessor implemented main frame. This particular desktop system is a hardware/software package that allows one to run System/370 application programs in a single user environment, to run as a terminal attached to a main frame host or to a run in a stand-alone mode, as required by the particular application. There are, of course, similar systems available from other manufacturers, all of which systems incorporate many of the same functions as the PC/XT370 although the manner and means of implementation does differ, in varying degrees, from system to system.
Due to revolutionary advances in chip densities and packaging, which have been accompanied by significant reductions in costs, many main frame features can now be implemented directly in a desktop system, while other features require some hardware and/or software assistance in order to make them available. The introduction and use of more powerful microprocessors such as, for example, the 8086 and 8088 from Intel Corporation and the 68000 from Motorola Corporation, added further to the list of functions it would be possible to implement in a desktop mainframe. This new breed of microprocessors is fully capable of running a large, enriched instruction set, such as that of System/370, although several of these microprocessors, working in concert with the aid of additional hardware and/or software support, would be required to effect instruction execution in an acceptable time period. It will also be appreciated that presently available microprocessors, while remarkable for the functions they do offer, are not capable of providing all mainframe capability without system compromise.
Thus, as in all data processing system designs, various trade-offs are made in order to optimize the price and performance of these microprocessor implemented desktop mainframes. One particular trade-off problem is posed by the need or desire to utilize certain mainframe functions and features that would be particularly difficult to provide in a microprocessor implemented desktop mainframe. Another type of trade-off problem is posed by the requirement that all architectural constraints of the emulated mainframe be adhered to so that user programs can be run without concern. One specific implementation problem of concern, due in part to such trade-offs being made, is that of accommodating the power and versatility of the relatively large control storage of a mainframe central processing unit (CPU) in the relatively small control storage of a microprocessing unit (MPU). In the System/370 world, for example, control store on the Model 138 is about 50 times larger than that available on the typical MPU chip. This disparity in control store capacity puts a premium on the amount and type of microcode that is placed into the MPU's control store.
This significant difference in the capacity of mainframe and MPU control storage capacity means that the performance of the MPU implemented mainframe system will be adversely affected each time an instruction or operation needs to be handled by reference outside of an MPU's on-chip control store. This control store capacity related performance problem is further exacerbated in a multi-MPU implemented system whenever the instruction fetching MPU passes control to another MPU for instruction execution or to obtain architectural information that is resident in control store or in the fetching MPU's registers. It should be remembered that in System/370 apparatus, and in many other mainframe systems as well, main storage ie architecturally defined as belonging exclusively to the user. It cannot be contaminated by the system control program itself or by an interprocessor interface and is therefore unavailable for control or scratchpad functions. Further, due to the address bus limitations inherent in current MPUs, there are not sufficient bits to define independent equivalents of the mainframe's virtual and control storage modules, it is not practical to assign one or more of the address lines for the exclusive purpose of steering accesses between main and control storage. Of course, a mainframe system would not have to deal with these problems since it has sufficient addressing capability for its needs and possesses a control store module that is large enough to accommodate all of its microcode and to provide the scratchpad area it requires.
In the multi-MPU implemented mainframe data processing system, the lack of large control storage space can be overcome using specially written microcode to handle the interface between the microprocessors, by hardware assists or through some combination thereof. Further, off-chip control store can be readily provided. This approach would require the use of special and additional microcode to support the enhanced interprocessor interface or hardware assists. However, this additional microcode would require on-chip control store residence which would put less instruction responsive microcode in the fetching microprocessor's control storage, a result that would adversely affect overall system performance. Thus, while it would be possible to accommodate the MPU's smaller control store and compensate for the problems it presents, the performance and/or cost penalties associated with straightforward solutions to that problem are too great to accept.